I am playing with the thought of using IMAP to send email from my mobile clients. The way this works is that mail is actually placed into a Maildir locally and synchronised with the IMAP server using a tool such as offlineimap. The Courier IMAP server supports such an outbox feature, for other servers you can use inotify or a cron job (I am planning to publish a writeup about my new mail setup sometime soon, so no scripts linked here yet). Anyway, it's trivial to get it working, and Dann Frazier has written it all up. The question is more whether I want to, or not. I am soliciting feedback. The advantages of using an IMAP-synchronised outbox are:

• The ability to review all mail to be sent while still offline. Using mutt, you can even edit them after "sending" but before they are actually sent. Undoubtedly, doing this often should be a hint to take more time before sending a message. However, at times there are good reasons why one might want to change a message which was composed e.g. on the plane (or not send it at all), and having to remove the message from the MTA queue and recreate it with the desired changes is unnecessarily time-intensive.

• Wherever you may roam, you can send mail even if port 25 is blocked (provided that the IMAP or SSH ports are open).

• All your mail is sent by a single host, so you don't have to worry about blacklisted IPs or disclosing information about your whereabouts.

• It's trivial to post-process mail, including training spamfilters with it (as ham) through a server-side pickup script, as well as e.g. checking for missing attachments locally (you need a local sendmail script for reasons documented here).

Any solution with advantages comes with disadvantages, and these are:

• Added complexity and brittleness: having mutt pipe mail to a custom sendmail-replacement script, which puts a message in place for synchronisation with offlineimap, and a server-side cron-job calling another custom script which pipes the mail(s) to be sent to the real sendmail binary all just seems a little less trustworthy than good ol' postfix delivering mail via a TLS-encrypted, client-cert or SASL-authenticated SMTP channel to a known mail relay.
• It's non-trivial to get meaningful notifications in case delivery of a message failed.
• Messages are only sent after IMAP synchronisation carried the mails to the server and the server-side pickup process sent them on. In my setup, this could introduce a delay of 30 minutes even when online, which may be rather undesirable in urgent matters. On the other hand, such delays could easily serve to reduce stress levels (I realise that's not a problem with a technical solution though).

Can you think of any other advantages or disadvantages? Do you use an IMAP-synchronised outbox and would like to share your experiences with me? Or do you have yet another solution? Write to me! NP: OSI: Free

Last night I decided to install etch on my pre-built MythTV system. The process is documented here

That's a mouthful. We had a customer asking for information on this, so I did a couple screen captures using byzanz to demonstrate. The first shows howto setup a system to do bios over serial. I did this w/ the remote java console, but you can also do this locally on the system (or the ActiveX console I suppose, but I've never tried this myself). In brief, you need to choose a serial port to map to the VSP (I use COM2 aka ttyS1), and tell the system to redirect the BIOS to the same serial port at your desired baud (115200 in this example). The second shows me initiating an ssh session, setting up a virtual cd-rom, and booting the debian installer. Of course you could use local media or even PXE boot. But either way you need to tell the installer to direct its console to the same port that you've configured as the VSP and at the same baudrate (console=ttyS1,115200n8 in this example). Note that if the screen goes blank after attempting to boot from the CD it is likely that the installer is displaying a graphical splash screen. Simply hit F1 to transitition to a text-mode help screen.

As there are currently four persons working on the next stable release (Dann Frazier, Luk Claes, Julien Danjou and me), we decided to track all issues for the next stable release (4.0r1) also in the Debian BTS. So if you would like to look what we currently consider for 4.0r1, have a look here. Before adding a bug (eg. with the command bts user debian-release@lists.debian.org . usertag 420759 + SRM) please contact the stable release team first, or even better, let the stable release team add your bug there on their own. Also, not all uploaded packages to proposed-updates will automatically considered for the next stable release. Update: With “contact the stable release team first” i do mean, please send requests to debian-release@lists.d.o, not contacting release team members in private over IRC or direct eMail. And NO, h01ger, cellphone is also not an option!!!1!!!elf!!!! release

I listened to my YP-U2 quite a bit on my recent travels. It worked fairly well. On my return, I remembered that I had a few comments to post from my old YP-U2 upgrade problems article... David Weinehall wrote:

"FWIW, my YP-U2 also has problems playing some oggs (nothing low bit-rate about them though; they're encoded with -q6); this is with version 1.418 of the firmware =/ On Samsung's site there seems to be a new version (1.43) available; too bad they don't mention what has been fixed."

dann frazier commented:

"Links/discussion about ogg support in these device can be found here: http://wiki.xiph.org/index.php/Talk:PortablePlayersSamsungYepp#YP-U2 I had to use a friend's Windows computer to do the upgrade :("

Erik Rossen writes:

"I have a Samsung YP-U2RZW (code for YP-U2, with Radio, 1GB of space, White case) that I bought today. The firmware version is "1.41 EU" according to system/system.var. And playback of medium quality OGG (44100 Hz, ~160032 bps) has serious stuttering problems. The latest firmware available on the UK Samsung site is 1.43. I too would love to know what files to copy to system/ (or wherever) so that I could do the upgrade from Linux, but I am probably going to end up booting WinXP for this task."

Scott Testerman comments:

"I don't have one of these players, but I wonder if this post is of any help to you? http://err.no/personal/blog/tech/2006-12-13-22-25_Samsung_Z5F.html"

Interesting, but sadly, the YP-U2 upgrades I have don't include a dat file. I wonder if this is what Samsung's support engineer was trying when he told me to copy all the files to the device's root. Does anyone have more info? Last time I chased Samsung about their promise of Linux upgrade instructions, I was asked to phone back in an evening when the member of staff who promised would be there. I still haven't had time to do that (there are other things to do most evenings - why won't they call me?). As far as I can tell, Samsung's Linux upgrade support sucks. I've bought a few Samsung devices and been fairly happy (far better than Canon, for example), but if I buy one again, I'll expect upgrades not to work.

We're trying to mitigate the severity of #404927 by working around the issue in udev. But, to do that, we need someone to provide us with udevinfo output for these controllers. If you have access to one, please help!

Lucas, try bip. It's not nearly as buggy as ctrlproxy, and allows multiple client connections, unlike dircproxy.

As announced in August, HP has now gone live with support for ProLiant. More information is available at http://hp.com/go/debian. Admittedly its odd to announce sarge support right before etch releases, but hey - we had to start somewhere. On a similar topic, I started a wiki a while ago to track the status of sarge and etch on various ProLiant models. I think it'd be cool to have similar pages for various vendors. By linking to d-i installation reports, I hope this will reduce duplicate information.

Good idea Tollef. Here's an xchat port.

hpodder is awesome, thanks John!

After doing the last 4 rounds mostly by hand, I've started automating a lot of the process with a make system. Essentially, make will find an appropriate machine, use pbuilder to perform the build, then bring all the results back locally. Considering I've had to restart builds 3 times this round, the extra time spent automating it has already made up for itself. Of course, I already see a number of places that need refactoring... I need help testing! Please checkout the wiki for details.

Since the sarge1 updates went out, Moritz, Horms & I (with help from others) have compiled a large set of issues (some very old ) that potentially affect woody/sarge/sid. We've made a few passes through them, and are now at a point where we could use some help resolving the last handful. Once we're done with that, I plan to start posting test builds on kernel.debian.net & tracking status on the wiki Woody builds still need some testing as well, if we're ever to get those out.

A while back I wrote an svn post-commit hook for the kernel repository that will look for new bug closures in the changelog, and mark them pending in the bts. Originally I'd rolled my own code to do the bts interaction, but someone pointed me to the bts command in the devscripts package, so it uses that now. The script is at svn.debian.org:~dannf/bts-mark-pending, if anyone else wants to use it.

Troy Heber and I have been setting up a multi-architecture Debian build cluster - basically a bunch of machines we can build/test kernels on. We got our hands on a Sun Blade 1000 a while back, and I had a good excuse to try and install it today. Troy said he'd tried one of the d-i nightlies, but had problems with it, so I decided to try sarge. I burned a sarge CD (which is 2.4 only, surprisingly), but it hangs after printing "Remapping the kernel...". Unlike other instances google finds, it never prints "done". I found that the net boot flavor has a 2.6 kernel - I tried it, but I get an oops as soon as it tries to load the scsi driver (sym53c8xx_2). It leaves modprobe hung in the D state, and all further modprobes hang behind it. Hoping that the cdrom boot method was to blame, I tried netbooting the 2.4 kernel flavor. This went smoothly, at first. But immediately after configuring the network w/ dhcp, the keyboard goes to hell. Only the left ctrl key seems to work (which I discovered using the tried and true bang-all-keys method), and it behaves like an escape. I tried a non-sun USB keyboard, but it had the same problem. I dug up an old non-USB sparc keyboard, but the box won't boot w/o a USB keyboard connected and d-i won't respond to the non-USB one anyway. I guess I could try running d-i with the text frontend, or maybe preseeding the whole thing... I remember some keyboard remapping on my sparc32 box that occurred when I moved to a 2.6 kernel - I wonder if something in userspace is attempting to compenate for that change? But that wouldn't explain why it only happens post-dhcp. Also.. I wonder why d-i is all monochrome on this box? Kind of annoying to navigate the menus when I can't see which option is highlighted. Unfortunately, this box has no serial port - I'll have to try to dig up one of the four port serial pci cards we once had lying around & try to setup serial console, which is what we'll want eventually anyway. Another option, I suppose, is to try installing woody then upgrading to sarge..

On various proliants, you can make it all the way through the install until the bootloader install. I'd noticed this before and had assumed it was a bug in grub. Turns out this is also a problem with lilo. I didn't pay much attention to it at the time because I could use the etch installer to install sarge and things worked fine. But, last week I had a reason to look deeper - turns out the problem is due to an outdated cciss driver. Replacing just the cciss.ko module with one backported from 2.6.12 makes the problem go away. That, and the fact that the 2.6.12 cciss driver added support for a number of new SmartArray cards, are a couple reasons I'd like to get this backport added to the Debian kernel in a point release. In the meantime, if someone needs an installer w/ a patched kernel, please contact me. Though, hopefully a sarge install with the etch installer will work fine.

I've not had much experience with git, but one feature I'm really liking is git-bisect. I often run into cases where a bug exists in one kernel but was fixed in another, and I need to pin the difference down to a single changeset. As an example, I recently discovered that an issue I'm working on in 2.6.8 no longer exists in 2.6.12. So, I went through the manual bisect to narrow the fix down to a changeset between 2.6.10-rc3 & 2.6.10. But that could be any of hundreds of changesets :( I decided it was a good opportunity to try git-bisect. It adjusts my tree to some intermediate state, I build and test. I tell git whether the results of my test were "good" or "bad", and it adjusts my tree once again. Very cool. The only annoying thing about this example is that I had to reverse the meanings of good & bad, because git bisect assumes that you're looking for the patch that fixes a build, not the one that broke it.

I recently blogged about how fixing d-i on cciss was just a matter of backporting a new version of the driver. Well, I was full of shit. Turns out my test case will give a false positive sometimes - oops. Anyway, the real fix requires backporting two fixes. Hopefully we can get this fix into a sarge point release at some point. On that note, I've started usertagging bugs that I think should go into a sarge kernel point release, should we ever do one (Note: the kernel team/stable release manager haven't discussed what is/is not acceptable in a stable kernel update, so this is just a wishlist at this point.) In my opinion, any localized fix that has already gone upstream and can be easily tested should be permitted. I'd really like to put driver updates in that category, but that opinion maybe tainted by my day job. We maintain a branch of the sarge d-i stack that has a side-goal of adding support for new HP hardware. We keep it as close to sarge as possible (backporting drivers to 2.6.8, for example) with the hope of pushing as much as possible into a sarge point release. Thanks to Andrew Patterson it has pretty recent cciss & fusion drivers. If there is interest, I could probably start posting these somewhere public.

I ran into a guy I knew from high school when I was back home - he told me about his band Liquid Cheese and that they were trying to book a show in Fort Collins. Last week I noticed a poster for their show outside of a small venue in town (SurfSide 7), so I showed up to check it out. The opening band was Thank You Donnie from Denver - a pop/punk 4-piece that were actually pretty good. Thank You Donnie finished their set around 11 & packed up their instruments. We waited 10 minutes.. 30 minutes... after a while, one of the bar employees took down the backdrop behind the stage. wtf? I went outside to call the guy I know from the band, and he says their booking agent forgot to e-mail them back to tell them they got the show - they were in Denver where they'd be playing the next night. Shit... well, sorry Shawn - I'll catch you guys next time. The cover was only $2, and it was an excuse to drink beer on a Tuesday night, so it wasn't all bad - plus I stole one of their posters.

I recently found out what these new-fangled podcast things are all about. I was playing with Rhythmbox the other day and noticed it had a built-in podcast feature, and I'd recently noticed that my favorite radio station is now doing podcasts, so I decided to investigate. After a few days of that, I decided that I approved of the concept. I bought a Neuros a year or two ago, and I spend about an hour or so bike commuting with it every day. Adding music to it is slow (USB 1.1), so I normally end up listening to the same music for a week or so. What I really want is to just plug it in at night & have fresh music on there ready to go the next day. But I also want to keep the flash full, so I don't want it to flush the old stuff unless it needs to - so I wanted something kinda like a FIFO. First thing I needed was something to track podcasts for me; rhythmbox is nice, but I need something scriptable. For now I'm using podracer. Its not very configurable, but it does the trick. I prototyped this all in shell using the positron command line interface, but then immediately rewrote it in python using the positron libraries instead. I then added a wrapper for cron to run that makes sure podcasts are up to date, the neuros is mounted (very easy now that udev automatically creates device files that are unique to a device under /dev/disk/by-id/), etc. It should be trivial to split the audio-device specific code into modules - which I'll need to do as soon as I find a physically smaller, logically larger flash player that works well with linux (I was looking at the iRiver T20, but have only read bad things about linux compatability).

I've been working on generating complete USB stick d-i installs - (with all necessary packages, not just base) on the stick. The way I ended up doing it is by starting with the d-i manual's instructions for booting from a usb stick w/ an embedded netinst ISO image. I did all this on the first 128MB partition of a 2G stick, then created an ext2 filesystem for a second partition containing an archive of all the packages I wanted available in the second stage (sarge-based d-i, so still has a second stage). I had problems getting the stick to boot from the first partition - the install-mbr tool didn't do the trick for me. Instead, I cat'd the mbr.bin file from the syslinux source package (not currently included in the syslinux binary package) onto the raw block device. Its also important to make sure your syslinux-configured partition has the bootable flag set (parted /dev/uba -- set 1 boot on) - syslinux doesn't appear to chain to partitions that don't. It might be better to combine the netinst ISO and the full archive into a single archive embedded in an ISO so that no manual mounting/apt configuration is necessary. But it'd also be cool if the ISO scanning in the second stage was capable of scanning local partitions for archives as well.